X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C92FE5.FF4699B0@onstor-exch02.onstor.net>; Thu, 16 Oct 2008 16:22:03 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C92FE5.FF4699B0"
Content-class: urn:content-classes:message
Subject: RE: Per Client Stats Func Spec
Date: Thu, 16 Oct 2008 16:22:03 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E0AE22BB9@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0C0D868E@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Per Client Stats Func Spec
Thread-Index: AckvrL8K2DI0rHN3SN+N+peSGIiaPgAAbvlQAAJ+iPAAARtX8AAASd4QAAnpLMA=
From: "Chris Vandever" <chris.vandever@onstor.com>
To: "Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>,
	"Amit Bothra" <amit.bothra@onstor.com>,
	"Jonathan Goldick" <jonathan.goldick@onstor.com>,
	"Rendell Fong" <rendell.fong@onstor.com>
Cc: "dl-Design Review" <dl-designreview@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C92FE5.FF4699B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

So, does this mean the stats are not reset when a vsvr is disabled?  We
should state the policy regardless.

What happens in a mixed revision cluster?  I assume the info is obtained
from another node by sending it a message.  What will an older node do
with said message?  Ignore it, so we timeout?  Crash?

ChrisV

_____________________________________________
From: Maxim Kozlovsky=20
Sent: Thursday, October 16, 2008 11:37 AM
To: Amit Bothra; Jonathan Goldick; Rendell Fong
Cc: dl-Design Review
Subject: RE: Per Client Stats Func Spec

The point that we should keep the counters for the connections that go
away should be the part of the functional spec.

_____________________________________________
From: Amit Bothra=20
Sent: Thursday, October 16, 2008 11:35 AM
To: Maxim Kozlovsky; Jonathan Goldick; Rendell Fong
Cc: dl-Design Review
Subject: RE: Per Client Stats Func Spec

I agree with Max that we should combine these PVRs together.=20

Also, I don't think the functional spec is the right document to discuss
the implementation. Though it's good to get pointers on how this can be
implemented. The implementation details should come in the Design
Document.

Thanks,
Amit



_____________________________________________
From: Maxim Kozlovsky=20
Sent: Thursday, October 16, 2008 11:24 AM
To: Jonathan Goldick; Rendell Fong
Cc: dl-Design Review
Subject: RE: Per Client Stats Func Spec

We have another similar PVR:

"User Auditing
Monitor all users that are currently accessing the services from a
filer.  Need to provide info on a per:
a) Volume / Share basis
b) Per Virtual Server basis. "

It looks like it makes sense to combine the two PVRs together. You
commands will have several additional parameters:

 "-v VOLUME"

Display the information for a particular volume.

-d SHARE

Display the information for a particular share, either NFS or CIFS.=20

-u=20

Turn on per user display. If the option is not specified, display per
client information only.

I don't like having the user specify either "cifs" or "nfs" all the
time, a lot of the customers are either cifs or nfs only and this only
makes the typing harder. I would rather make it an option, like

-p protocol.

Filter by protocol. If not specified, display all protocols.

Regarding the implementation:=20

Keeping track of NFS users requires a hash lookup on each RPC, and the
information can not be kept in the connection structure.=20

The CIFS usage information should be kept in the tree connection
structure. We should preserve the information when the tree connection
goes away. When this happens the counters should be moved into the
global hash.=20

When data from the global hash is recycled, we should save this
somewhere so the percentages and totals continue to make sense if we
have to recycle the information about a client with high usage. The
counters for the unknown usages should display as "unknown" or something
like that.

The overhead for the spec purposes will probably be minimal. The spec
does require a lot of clients to run. The lookups should hit the cache
most of the time. In case this turns out not true, we should plan for
implementing a persistent option to turn the feature off.

We'll need to pick up the value for the maximum number of the hash
entries we are going to keep.

_____________________________________________
From: Jonathan Goldick=20
Sent: Thursday, October 16, 2008 9:55 AM
To: Rendell Fong
Cc: dl-Design Review
Subject: RE: Per Client Stats Func Spec

1.	Section 3, the intent is to get this into 3.3.2/4.0.2 which is
end of year, unless you are saying that cannot be done.
2.	This feature should have an enabled/disabled option; unless the
performance impact is negligible I would not have it turned on all of
the time.  That would require more CLI options and a decision whether it
is persistent across reboots.
3.	A reasonable approach is to keep stats in struct acpu_conn which
is directly accessible without any extra lookup work.  This might make
the overhead negligible and allow for an always on approach.  Note that
when a client disconnects we would lose the stats, even if a moment
before they were among the most active.  It's probably not worth trying
to preserve the stats for the last N clients that disconnected and then
restore the stats if there is a match on reconnect, but it wouldn't be
all that difficult either.
4.	What is the limit on the number of clients you will keep if any?
What is the testing limit for clients?


_____________________________________________
From: Rendell Fong=20
Sent: Thursday, October 16, 2008 9:32 AM
To: dl-Design Review
Subject: Per Client Stats Func Spec

Please review the Per Client Stats functional spec (ECR TED20020) for
Kegg.

\\mightydog\software\Kegg\functional specs\per client stats.doc


------_=_NextPart_001_01C92FE5.FF4699B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: Per Client Stats Func Spec</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">So, does this mean the stats are not reset when a vsvr is =
disabled?</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us">&nbsp;<FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial"> We =
should state the policy regardless.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">What happens in a mixed revision cluster?&nbsp; I assume =
the info is obtained from</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"> <FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">an</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">other =
node by sending</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"> <FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">it a =
message.&nbsp; What will an older node do with said message?&nbsp; =
Ignore it, so we timeout?&nbsp; Crash?</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">ChrisV</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma">_____________________________________________<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">From:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Maxim Kozlovsky<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Sent:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Thursday, October 16, =
2008 11:37 AM<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">To:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Amit Bothra; Jonathan =
Goldick; Rendell Fong<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Cc:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> dl-Design Review<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Subject:</FONT></B></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma"> RE: Per Client Stats Func Spec</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">The point that we should keep the counters for the =
connections that go away should be the part of the functional =
spec.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma">_____________________________________________<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">From:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Amit Bothra<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Sent:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Thursday, October 16, =
2008 11:35 AM<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">To:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Maxim Kozlovsky; Jonathan =
Goldick; Rendell Fong<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Cc:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> dl-Design Review<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Subject:</FONT></B></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma"> RE: Per Client Stats Func Spec</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">I agree with Max that we should combine these PVRs =
together. </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Also, I don&#8217;t think the functional spec is the =
right document to discuss the implementation. Though it&#8217;s good to =
get pointers on how this can be implemented. The implementation details =
should come in the Design Document.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Thanks,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Amit</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"></SPAN><A NAME=3D""><SPAN =
LANG=3D"en-us"></SPAN></A></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma">_____________________________________________<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">From:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Maxim Kozlovsky<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Sent:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Thursday, October 16, =
2008 11:24 AM<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">To:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Jonathan Goldick; Rendell =
Fong<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Cc:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> dl-Design Review<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Subject:</FONT></B></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma"> RE: Per Client Stats Func Spec</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">We have another similar PVR:</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">&#8220;User Auditing</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Monitor all users that are currently accessing the =
services from a filer.&nbsp; Need to provide info on a =
per:</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">a) Volume / Share basis</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">b) Per Virtual Server basis. &#8220;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">It looks like it makes sense to combine the two PVRs =
together. You commands will have several additional =
parameters:</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&#8220;-v VOLUME&#8221;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Display the information for a particular =
volume.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">-d SHARE</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Display the information for a particular share, either =
NFS or CIFS. </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">-u </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Turn on per user display. If the option is not specified, =
display per client information only.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">I don&#8217;t like having the user specify either =
&#8220;cifs&#8221; or &#8220;nfs&#8221; all the time, a lot of the =
customers are either cifs or nfs only and this only makes the typing =
harder. I would rather make it an option, like</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">-p protocol.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Filter by protocol. If not specified, display all =
protocols.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Regarding the implementation: </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Keeping track of NFS users requires a hash lookup on each =
RPC, and the information can not be kept in the connection structure. =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">The CIFS usage information should be kept in the tree =
connection structure. We should preserve the information when the tree =
connection goes away. When this happens the counters should be moved =
into the global hash. </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">When data from the global hash is recycled, we should =
save this somewhere so the percentages and totals continue to make sense =
if we have to recycle the information about a client with high usage. =
The counters for the unknown usages should display as =
&#8220;unknown&#8221; or something like that.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">The overhead for the spec purposes will probably be =
minimal. The spec does require a lot of clients to run. The lookups =
should hit the cache most of the time. In case this turns out not true, =
we should plan for implementing a persistent option to turn the feature =
off.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">We&#8217;ll need to pick up the value for the maximum =
number of the hash entries we are going to keep.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma">_____________________________________________<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">From:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Jonathan Goldick<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Sent:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Thursday, October 16, =
2008 9:55 AM<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">To:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Rendell Fong<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Cc:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> dl-Design Review<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Subject:</FONT></B></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma"> RE: Per Client Stats Func Spec</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">Section 3, the intent is to get this into =
3.3.2/4.0.2 which is end of year, unless you are saying that cannot be =
done.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">This feature should have an =
enabled/disabled option; unless the performance impact is negligible I =
would not have it turned on all of the time.&nbsp; That would require =
more CLI options and a decision whether it is persistent across =
reboots.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">A reasonable approach is to =
keep stats in struct acpu_conn which is directly accessible without any =
extra lookup work.&nbsp; This might make the overhead negligible and =
allow for an always on approach.&nbsp; Note that when a client =
disconnects we would lose the stats, even if a moment before they were =
among the most active.&nbsp; It&#8217;s probably not worth trying to =
preserve the stats for the last N clients that disconnected and then =
restore the stats if there is a match on reconnect, but it =
wouldn&#8217;t be all that difficult either.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">4.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">What is the limit on the =
number of clients you will keep if any?&nbsp; What is the testing limit =
for clients?</FONT></SPAN>
</P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma">_____________________________________________<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B></B></SPAN><B><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma">From:</FONT></SPAN></B><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Rendell Fong<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B></B></SPAN><B><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma">Sent:</FONT></SPAN></B><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Thursday, October 16, 2008 9:32 AM<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B></B></SPAN><B><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma">To:</FONT></SPAN></B><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma"> dl-Design Review<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B></B></SPAN><B><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma">Subject:</FONT></SPAN></B><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Per Client Stats Func =
Spec</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">Please review the Per Client Stats functional spec (ECR =
TED20020) for Kegg.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"></SPAN><A =
HREF=3D"file://\\mightydog\software\Kegg\functional specs\per client =
stats.doc"><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">\\mightydog\software\Kegg\functional specs\per client =
stats.doc</FONT></U></SPAN><SPAN LANG=3D"en-us"></SPAN></A><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C92FE5.FF4699B0--
